Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-089.TXT

Text File | 1992-06-30 | 46.5 KB | 1,257 lines

C.S.M.P. Digest             Thu, 21 May 92       Volume 1 : Issue 89

Today's Topics:

    adding menu item to finder
    File question in C
    Sound Manager Quickie Question
    adsp buffer size and blocking -- you MUST have had this
    MPW Cs Preprocessor
    What is the current status of MacTutor?
    Printing
    programming editor for Quadra
    What's the best debugger?


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Brad Ashby)
Subject: adding menu item to finder
Organization: University of Nebraska at Omaha
Date: Sun, 19 Apr 1992 15:10:11 GMT

Does anyone know if it is possible to add a menu item to one of
the menu items on the finder?  What I want to do is add an item on
the 'View' menu, to view by creation date.  Can anyone give me a
pointer on how to accomplish this?




+++++++++++++++++++++++++++

From: [e-mail] (Pete Gontier)
Date: 20 Apr 92 05:51:33 GMT

In <ashby.703696211@odin> [e-mail] (Brad Ashby) writes:

>Does anyone know if it is possible to add a menu item to one of
>the menu items on the finder?  What I want to do is add an item on
>the 'View' menu, to view by creation date.  Can anyone give me a
>pointer on how to accomplish this?

There are two parts to your problem. One is adding the menu -- that's
a simple matter of patching MenuSelect and DrawMenuBar and doing the
appropriate thing to create the illusion that the menu is there. Or,
just patch DrawMenuBar and insert a menu which belongs to a driver
you've installed -- and in this case, you can leave it in the bar.
Check, of course, that you've got Finder before you go installing
menus; you can do this in System 7 with GetProcessInfo, and in
System 6 I suppose you can just see if CurApName (in low memory) looks
something like "Finder" (there are probably better ways).

The real challenge, however, is in getting Finder to cooperate with
your view idea. Finder is just another application, and it has code
and data structures just like any other application. Persuading it to
do something it was not designed to do is not a simple matter of passing
it a parameter. Unless you find that Finder actually does have code to
view by creation date and it just happens not to be using it, you're
out of luck.
- --
 Pete Gontier // EC Technology // [e-mail]

---------------------------

From: [e-mail]
Subject: File question in C
Date: 19 Apr 92 12:08:48 EDT
Organization: Univ of Miami IR

Hello all,

    I have what is porbably a simple question but I just can't figure it
out. I'm using Think C 5.0 and trying to open a file fro writing...I use
StandardPutFile() to get a StandardFileReply...then call FSpCreate to create
the file, then FSpOpenDF to open the files data fork...all of these calls
return a Zero error code...(no error, right).... but when I then call FsWrite
I get a -34 (Which seems to be a disk full error) and the disk is certainly
not full...
the code looks like this...it compiles...and I double checked all the types
to make sure they are correct..

StandardPutFile("\pFilename:",filename,&reply);

if (reply.sfGood)
    rc = FSpCreate (&(reply.sfFile),creator,fileType,reply.sfScript);
else
    return;
rc = FSpOpenDF (&(reply.sfFile),fsWrPerm,&refNum);
rc = SetFPos (refNum,fsFromStart,0);
rc = FSWrite (refNum,&bufCount,(Ptr)buffer);

Anyone have any suggestions?
Thanx
- --
Ian Sullivan
*******************************************************************************
**[e-mail]      %   "Friendly Fire"..There is no such thing   **
**[e-mail]      %    Remember your gun was made by the        **
**[e-mail]            %    lowest bidder.                           **
**[e-mail]      %                                             **
**                             %                                             **
**UUU    UMUMMM     MMMMMM     %                                             **
**UUU    UMU MMM   MMM MMM     %   "Skate to Kill--Kill to Skate"            **
**uUU    UMU  MMM MMM  MMM     %   "Life's been good to me so far..." -J.W.  **
**UUUUUUUUMUof MMMMM   MMM     %   "Give it a while." -Me.                   **
*******************************************************************************
Yes..yes...I know I spelled it wrong......whatever it was. ;)

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 19 Apr 92 20:17:49 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] writes:

   rc = FSWrite (refNum,&bufCount,(Ptr)buffer);

   Anyone have any suggestions?

Are you sure bufCount is a long integer ?

   [ 20 lines .sig deleted ]

Your .sig is gross. Think of all the people receiving News by 2400
baud.

- --
"You should meet yourself someday. I'm sure you would hate it."
- - Me: [e-mail]; Jon W{tte (The Diplomat - NOT!)

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Sun, 19 Apr 1992 21:07:52 GMT

[e-mail] (Jon W{tte) writes:
>> [e-mail] writes:
>>  rc = FSWrite (refNum,&bufCount,(Ptr)buffer);
>>
>>  Anyone have any suggestions?

>Are you sure bufCount is a long integer ?

And especially, are you sure you set bufCount to a reasonable value before
writing ?

>   [ 20 lines .sig deleted ]

>Your .sig is gross.

Seconded.

Matthias

- -----
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_

---------------------------

From: [e-mail] (John Miller)
Subject: Sound Manager Quickie Question
Date: 19 Apr 92 18:05:55 GMT
Organization: Eastern Illinois University


Hi All,

How do you get rid of the clicks and pops just before the first sampled
sound after opening a sound channel?

Thanks,

John


- --
John Miller
Music Theory
Eastern Illinois University

+++++++++++++++++++++++++++

From: [e-mail] (Alan J Rosenthal)
Organization: Dynamic Graphics Project, University of Toronto
Date: 19 Apr 92 18:57:04 GMT

[e-mail] (John Miller) writes:
>How do you get rid of the clicks and pops just before the first sampled
>sound after opening a sound channel?

You pad the end of the previous sound you played (on that channel?) with 128s.
Strange but true.  I have no idea how many 128s, but the size of the buffer on
the chip is 1K, so 1K of 'em should suffice.

This is assuming that your sound itself doesn't have clicks in it.  If
you just chop signals up, you introduce clicks (think of what it would do
to a fourier analysis at that point).  You have to put in an attack and a
decay.  (SoundEdit's "envelope" feature allows you to do this.)

---------------------------

From: [e-mail] (Alan J Rosenthal)
Subject: adsp buffer size and blocking -- you MUST have had this
Date: 19 Apr 92 19:53:17 GMT
Organization: Dynamic Graphics Project, University of Toronto


Even though this isn't in the faq, it must be a common problem for anyone
writing adsp code, or I'm doing something really really wrong.

I've written a non-trivial library of adsp and related code.  It works in all
respects but one:  Under circumstances I can't predict, the sender waits, not
sending, forever.  This is remedied by increasing the buffer size (I'm not sure
whether on the receiving or sending end, since I did both).  However, this
waiting has two strange characteristics:  one, it happens even though the
buffers are large enough (yes, I know about the minimum size; one example is in
sending 3000-byte messages with a 3000-byte buffer), and two, it reports that
ZERO bytes have been sent so far, i.e. it doesn't manage to send ANY of it.

Does this sound familiar to anyone, or do I have to produce a sample program
for y'all to look at?  (I've been putting off posting for months because I
haven't gotten around to it...)  Unless I'm doing really something weird, it
seems that most people must run into this problem.

thanks for any help,
ajr

+++++++++++++++++++++++++++

From: [e-mail] (Roby Sherman)
Date: 20 Apr 1992 09:37:08 -0400
Organization: The Tao of Programming

In <[e-mail]> [e-mail] (Alan J Rosenthal) writes:


>Even though this isn't in the faq, it must be a common problem for anyone
>writing adsp code, or I'm doing something really really wrong.

>I've written a non-trivial library of adsp and related code.  It works in all
>respects but one:  Under circumstances I can't predict, the sender waits, not
>sending, forever.  This is remedied by increasing the buffer size (I'm not sure
>whether on the receiving or sending end, since I did both).  However, this
>waiting has two strange characteristics:  one, it happens even though the
>buffers are large enough (yes, I know about the minimum size; one example is in
>sending 3000-byte messages with a 3000-byte buffer), and two, it reports that
>ZERO bytes have been sent so far, i.e. it doesn't manage to send ANY of it.

>Does this sound familiar to anyone, or do I have to produce a sample program
>for y'all to look at?  (I've been putting off posting for months because I
>haven't gotten around to it...)  Unless I'm doing really something weird, it
>seems that most people must run into this problem.

I ran into this problem while I was working on a network game. The problem
with small buffers is that when you send data out to a destination, if that
recipient is not ready to receive your transmission, it will sit in your
buffer until he is. If your buffer is small, it will hang as soon as you use
up all of your buffer space. The solution is to put in MORE polling checks,
so that if your friend is in a dialog or something, it will not hang. I
ended up putting a poll request in my event loop and and made a filter
routine for my dialogs and alerts that polled for ADSP transmissions as
well, that took care of most all my problems except for one. *IF* the
recipient went to the menu bar and help down the mouse too long while
selecting an item, the queue would stack up again causing the same problem.
The only way around this is to make a larger buffer and PRAY that they are
not incredibly slow with going to menu selections.



            --Roby
- --
[e-mail]                    Roby Sherman

+++++++++++++++++++++++++++

From: [e-mail] (Alan J Rosenthal)
Date: 20 Apr 92 15:57:32 GMT
Organization: Dynamic Graphics Project, University of Toronto

[e-mail] (Roby Sherman) writes:
>The problem with small buffers is that when you send data out to a
>destination, if that recipient is not ready to receive your transmission, it
>will sit in your buffer until he is.

I have a buffer size equal to my message size, and there is nothing using too
much cpu time on either machine, nor is the mouse being held down, and it's
just sitting there looping and printfing that it has sent zero bytes so far!
(It also hangs without the printfs.)  The problem went away when I upped the
buffer size (somewhat randomly), but I need to know how much larger I have to
make the buffer than my maximum message size to avoid this situation!

---------------------------

From: [e-mail] (Jerome Jahnke)
Subject: MPW Cs Preprocessor
Date: 20 Apr 92 05:13:58 GMT
Organization: Biology Learning Center

Boy, It seems sometimes the dumbest things happen late at night. I have been
working on some software. In my #defines is a statement which looks something
like this:

#define TimeStamp (char *) "Some stuff on "__DATE__" at "__TIME__" MST."

OK now I do understand how proprocessors are supposed to work, or at least I
thought I did. Because from Think C's PreProcessor I get:

printf("%s", "Some stuff on Apr 19 1992 at 21:39:21 MST.");

This is cool and EXACTLY what I want. Think C is resolving __TIME__ and
__DATE__ and then concatenating two or more successive string constants.

What does MPW C do??

printf("%s","Some stuff on ""Apr 19 1992"" at ""21:40:37"" MST.");

And of course we all know that the compiler will choke on that as surely as I
would a week old chicken bone. What it looks like MPW C is doing is
concatenating string FIRST and then resolving reserved symbols. This to my
mind is a braindead way of doing this.

Does anyone out there know how I can script this into a make file, so I don't
have to use toolbox commands to do something just to get my statement to print
out? I need to time stamp some stuff, and really thought the preprocessor
could handle it for me. I think I will port my sample to a unix machine
tomorrow to see how THEY handle it. But I would think it would be reserved
symbols first and then string concatenation.

Anyway, any help would be appreciated, and if someone could tell me if I am
being too picky, or if this is a bonna-fida bug, and might get fixed for
ETO 8?

I am using C v3.2.1

Jer,
- ----
Jerome Jahnke
Biology Learning Center
University of Arizona
'[e-mail]' or [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Organization: University of Illinois at Urbana
Date: Mon, 20 Apr 1992 07:14:53 GMT

[e-mail] (Jerome Jahnke) writes:

>Anyway, any help would be appreciated, and if someone could tell me if I am
>being too picky, or if this is a bonna-fida bug, and might get fixed for
>ETO 8?

Well, now you've done it. You've gone and published an Apple bug on the net.
Now they know that someone's working around it and will *never* fix it, because
that would break existing software!

Well. Apple's MPW 3.1 docs discuss their stupid cpp and they haven't fixed it
yet. Don't expect it for ETO8.

Here's some stuff from one of my makefiles:

Version.r D Version.h
    Echo "// Tool version ID strings (for use in rez)" > Version.h
    Echo '#define VersPackageLong "NCSA Macintosh Tool 1.0"'  >> Version.h
    Echo '#define VersPackageShort "1.0"' >> Version.h
    Echo '#define VersProgramLong "1.0.0, '`Date -a`'"' >> Version.h
    Echo '#define VersProgramShort "1.0.0"' >> Version.h
    #SetFile -m . Version.r

Version.h D every_time

every_time D
    # this line intentionally left blank

The "D" is an option-f (too tired to fix it, and haven't convinced Scott to put
in code in Telnet to map 8-bit Mac characters yet).

Here's Version.r:

#include "SysTypes.r"
#include "Version.h"

Resource 'vers' (2, purgeable)
{
    0x02, 0x00, beta, 0x03, verUs,
    VersPackageShort,
    VersPackageLong;
};

Resource 'vers' (1, purgeable)
{
    0x02, 0x00, beta, 0x03, verUs,
    VersProgramShort,
    VersProgramLong;
};


This will rez *every* time so I've disabled it. I think that #setfile will
reenable it, but, hey, you're a programmer and this is the source, so if it's
broke, you can fix it.

Mark L
- --
Mark Lanett, Software Tools Group, NCSA; [e-mail]; NCSA.STG (AppleLink)

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 20 Apr 92 09:39:45 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Jerome Jahnke) writes:

   #define TimeStamp (char *) "Some stuff on "__DATE__" at "__TIME__" MST."

   thought I did. Because from Think C's PreProcessor I get:
   printf("%s", "Some stuff on Apr 19 1992 at 21:39:21 MST.");

   What does MPW C do??
   printf("%s","Some stuff on ""Apr 19 1992"" at ""21:40:37"" MST.");

New-style string constants can be written as several constants:

"this " "is " "one " "constant."

Try just adding spaces around __DATE__ and __TIME__

- --
"You should meet yourself someday. I'm sure you would hate it."
- - Me: [e-mail]; Jon W{tte (The Diplomat - NOT!)

+++++++++++++++++++++++++++

From: [e-mail] (Charlie Reiman)
Organization: University of Illinois at Urbana
Date: Mon, 20 Apr 1992 20:15:33 GMT

[e-mail] (Jon W{tte) writes:

>> [e-mail] (Jerome Jahnke) writes:
>   #define TimeStamp (char *) "Some stuff on "__DATE__" at "__TIME__" MST."
>   thought I did. Because from Think C's PreProcessor I get:

>   printf("%s", "Some stuff on Apr 19 1992 at 21:39:21 MST.");

>   What does MPW C do??

>   printf("%s","Some stuff on ""Apr 19 1992"" at ""21:40:37"" MST.");

>New-style string constants can be written as several constants:
>"this " "is " "one " "constant."
>Try just adding spaces around __DATE__ and __TIME__

Yes and no. This is legal ANSI, but (as noted by Mark) MPW's cpp is busted
big time. If I could find my @$%@# manual, I'd quote the "Known Bugs"
section and let you know what the story is. Unfortunately, I must wing it.

The problem is that string concatenation only works when NONE of the
strings parts are the result of a macro expansion. (Or something along
those lines).

This program will not compile:

>#define FOO "a string.\n";
>
>main() {
>    printf("This is" FOO);
>    }

This program will compile just fine:

>main() {
>    printf("This is" "a string.\n");
>    }

It looks like someone decided to detect string concatenation a few
passes too early in the compiler.

MPW's cpp has a few other nasty habits. I highly recommend RTFM, esp.
the section about "Known Bugs." I know of at least one bug not
documented:  You cannot stringify __LINE__.
- --
Charlie Reiman - [e-mail]
"People are going to take to voice input like lemmings to the sea."
                     -Tony Bove (MacWeek V.6 N.13)


+++++++++++++++++++++++++++

From: [e-mail] (Jerome Jahnke)
Date: 20 Apr 92 17:59:41 GMT
Organization: Biology Learning Center

In article <[e-mail]>, [e-mail] (Mark Lanett) writes:
>
> [e-mail] (Jerome Jahnke) writes:
>
> >Anyway, any help would be appreciated, and if someone could tell me if I am
> >being too picky, or if this is a bonna-fida bug, and might get fixed for
> >ETO 8?
>
> Well, now you've done it. You've gone and published an Apple bug on the net.
> Now they know that someone's working around it and will *never* fix it, because
> that would break existing software!
>
> Well. Apple's MPW 3.1 docs discuss their stupid cpp and they haven't fixed it
> yet. Don't expect it for ETO8.
>

.. Helpful advice deleted...

> This will rez *every* time so I've disabled it. I think that #setfile will
> reenable it, but, hey, you're a programmer and this is the source, so if it's
> broke, you can fix it.

Ratzen Fratzen, boy does that make me mad. Oh well I found a slightly easier
way. I am just running the code through the preprocessor twice. Jeeze what a
stupid way to run popcorn stand.

>
> Mark L
> --
> Mark Lanett, Software Tools Group, NCSA; [e-mail]; NCSA.STG (AppleLink)
>

Jer,
- ----
Jerome Jahnke
Biology Learning Center
University of Arizona
'[e-mail]' or [phone]

---------------------------

From: [e-mail] (Andreas Koch)
Subject: What is the current status of MacTutor?
Date: 20 Apr 92 21:16:15 GMT
Organization: TU Braunschweig,Informatik,EIS,West Germany

The subject line says it all. I remember someone posting a while ago
that MacTutor was bought by some other publisher, that there would
be some delays but they expected to be back in April and that they
would add the missing issues to existing subscriptions.

The last issue I have is October 1991. Have any issues appeared since?

Thanks for any info.

+++++++++++++++++++++++++++

From: [e-mail] (Daryl Spitzer)
Date: 20 Apr 92 23:34:59 GMT
Organization: MIND LINK! - British Columbia, Canada

I found this on AppleLink:

Announcing MacTutor Version 2.0...

As many of you already know, MacTutor has been on hiatus for the last several
months.  During this time, there has been a change of ownership, change of
staff and an office move.  The magazine has undergone a complete revamping.  On
Friday, April 17, 1992, MacTutor version 2.0 shipped out to subscribers and
dealers.  This first issue of the new magazine is called the April/May issue.
>From this point on, the magazine will return to its regular monthly schedule.
The first issue has a full description of what has happened at the magazine as
well as what will be happening in the future.  Check it out!

For more information, please call Xplain Corporation at 310/575-4343 or
AppleLink us at MACTUTOR.

Let us know what you think.

Thanks,
Neil Ticktin
Editor, MacTutor Magazine

Author: MACTUTOR
- --
- -------------------------------------------------------------------
 [e-mail]     "Life isn't just, life just is."
         [e-mail]              -- Me  (I think.)
       [e-mail]
- -------------------------------------------------------------------

---------------------------

From: [e-mail] (Jon McKeeby)
Subject: Printing
Date: 25 Mar 92 15:42:10 GMT
Organization: George Washington University


 I am need to print a screen upon user selection.  I have the code working
except for one problem: I need it to print in the wide orientation.  What
do I need to set to get a grafport to print in the wide direction.

I do not want the user to select settings to change the size or the orientation
but to do it transparent to the user.

I also need to know:
  How to determine if a printer is connected?
  Is a printer selected.
  Is there any variation between printers connected through appletalk and
  those which are not connected through appletalk?


Thank you.

Jon


+++++++++++++++++++++++++++

From: [e-mail] (Danny McCampbell)
Date: 3 Apr 92 14:06:59 GMT
Organization: University of Tennessee

Hi all,

I have slowly but sure been learning pascal and writing some pretty
neat stuff to work on my mac.  Well, I am up to the point where
I want to print from an application I wrote.  I do not even know
where to start.  Could someone please help me out and tell me
exactly what I have to do to set up a procedure that will call
the print dialog and then send something to the printer.

By the way, I will printing pictures from modal dialogs.

Thanks.

Danny McCampbell

+++++++++++++++++++++++++++

From: [e-mail] (Mike Smithwick)
Organization: SF-Bay Public-Access Unix
Date: Tue, 7 Apr 1992 03:12:34 GMT

[]

I am working on a screen-dump routine for my SW, and have it working
fine on an antique imagewriter, but it fails on a Laser printer.

PrError returns "-192" after the PrOpenDoc() call which means "resource not
found"?!?!?! What resource do I need for working with a laser printer.
I thought the interface was supposed to be transparent to the programmer.

mike

- --
"There is no problem too big that can't be solved with high explosives"-Rush

Mike Smithwick - ames!zorch!mike


+++++++++++++++++++++++++++

From: [e-mail] (Danny McCampbell)
Date: 7 Apr 92 19:21:52 GMT
Organization: University of Tennessee

I have written a small program that involves some text (more than a pages
worth) that I want to send to the printer.   Well, my program uses modal
dialogs and of course in one of the dialogs there is a print button.

My question is where should I store the text to print to the printer
and how do I load the text in memory and send it to the printer correctly
formatted?

Right now I have the text store in seperate PICT resources (because there
is too much to fit on one screen).  I have added more and back buttons
that when simply clicked on back up a screen or go forward a screen.

I cannot print the PICT's to the printer because that will not look right.
I want to store the text as a document like format, but in the resource
file.  I do not want to use a seperate file if I do not have to.

I hope this is clear.  Oh, I did want to mention that I want be using the
print dialogs.  When the user clicks the print button, I want to just
send the text to the printer and thats it.  Thanks in advance.

Danny McCampbell

+++++++++++++++++++++++++++

From: [e-mail] (Mike Smithwick)
Organization: SF-Bay Public-Access Unix
Date: Wed, 8 Apr 1992 06:51:01 GMT

In article <[e-mail]> [e-mail] (Mike Smithwick) writes:
>[]
>
>I am working on a screen-dump routine for my SW, and have it working
>fine on an antique imagewriter, but it fails on a Laser printer.
>
>PrError returns "-192" after the PrOpenDoc() call which means "resource not
>found"?!?!?! What resource do I need for working with a laser printer.
>I thought the interface was supposed to be transparent to the programmer.
>

One additional note. Yes, the laser printer is hooked up and WORKS with
other software, but fails with mine.

mike



- --
"There is no problem too big that can't be solved with high explosives"-Rush

Mike Smithwick - ames!zorch!mike


+++++++++++++++++++++++++++

From: [e-mail] (Danny McCampbell)
Date: 8 Apr 92 17:18:39 GMT
Organization: University of Tennessee

Hi all, I posted this message yesterday my our news server went south
so I am posting it again just to be sure you all read it.

I have a small program using modal dialogs that I want to be able to
print some text from.  Well, in one of the dialogs I have a print
button.  When this button in pressed I want some text printed and
formatted correctly to the laserwriter.

My question is where can I store the text.  The actual text that
the user sees on the screen is located in seperate pict resources.
I want the text to print just like a paged document would.

Also, if I do lets say store the text in a text resource how do
I load the text into memory to send to the printer.

I have read the tech notes apple puts out and have looked through
Inside Mac V. I, II, and IV.  I still seem to be puzzled.

Thanks in advance.

Danny

+++++++++++++++++++++++++++

From: [e-mail] (G. S. Marzot(Joe))
Date: 20 Apr 92 21:22:03 GMT
Organization: The MITRE Corporation

I posted this problem a little while ago but got no response. I can not
beleive that someone else has not experienced it, since I have seen it in
another developers program as well.

When I go to print an 8-bit deep pixmap using copybits and surrounded by
all the necessary Print manager calls, all seems to go well but the
printed image comes out with some fuzz(i.e., random bits) on a strip at
the edge.  I have set clipping regions and done everything else I can
think of.

Please, if anyone has dealt with this before and solved it I would be
grateful for a clue.
Thanks, GSM

routine disclaimer

---------------------------

From: [e-mail] (Tom Drake)
Subject: programming editor for Quadra
Date: 5 Apr 1992 23:45:22 GMT
Organization: U.C. San Diego - SIO

Is there a good editor for programming (C, Fortran, etc) on
the Quadra that can be had cheaply.  Something along the lines
of the old Apple editor Edit (maybe there's a newer incarnation
of this) or the THINK C editor.
Thanks, Tom Drake


+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 10 Apr 92 23:02:31 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Tom Drake)
writes:
>
> Is there a good editor for programming (C, Fortran, etc) on
> the Quadra that can be had cheaply.  Something along the lines
> of the old Apple editor Edit (maybe there's a newer incarnation
> of this) or the THINK C editor.
> Thanks, Tom Drake

I like Alpha, it's a PD editor which has a lot of Emacs bindings
(which is the reason I like it, somehow years of Emacs use has
hard-wired my brain to the key bindings...). Alpha should
we available at sumex-aim and similar ftp sites. And yes, it
has electric-C mode!



Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Chris Hanson)
Organization: Gagme Public Access UNIX, Chicago, Illinois.
Date: Thu, 16 Apr 1992 21:27:43 GMT

I don't know how much like Edit you want, since my suggestion is of a
decidedly different flavor, but here it goes...

I use MicroEMACS 3.10 for all my editing on the Mac, because

a) I have it on my PC and it's at Gagme as well (see Organization:),
   and I like the cross-platform stuff.

b) It has a command language.

c) It has a really cool C command page (NOT the builtin cmode; a much
better page is available).

I can't remember the name of the dude that ported it... the readme
said he was giving back the Mac II he wrote it on (to go to the Other
Side -- programming for that hated GUI kidstuff).  Anyway, I happen to
like it and can send it to ya if you can't find a copy.  It should
work on your Quadra -- it's worked on EVERY machine I've tried it on
without a hitch.  Also, I can't find source, anyone with source to
this (with the Mac-specific parts), please drop me a note, I NEED this
to find out how to do some other display stuff (I want to attempt a
REAL emacs port).  Thanx.

  CYA,
Chris

- --
===============================================================================
[e-mail]    | "People are mostly stupid and hateful and cruel to
Chris Hanson        | one another but--hell; let's save the world's a*
Identify the quote! ->    | anyway.  It's better than being bored." -- Rook

---------------------------

From: [e-mail] (Scott Bronson)
Subject: What's the best debugger?
Date: 6 Apr 92 00:30:29 GMT

I have reached a stage in my projects where I would like to use
the most effective debugger know to Macintosh.  I own TMON, I have
MacsBug in the wings and waiting, and (I bought this LONG ago) Jasik's
MacNosy/Debugger.  I acutally really like debugging software because
the gut-grinding frustration you feel is overshadowed by the incredible
elation of finally stomping that bug out.  Or, perhaps, I'm taking
debugging way to personally.

I would just like to hear what people thing of the object-level debuggers
out today.  Incidentally, I use THINK C for everything right now, but
I plan on buying MPW eventually (soon as I can scrape enough cash
together).  Following are my impressions of the products I own.  Do
I know what I'm talking abouut?  Well, you tell me by following up
to this post.  :-)

Or, if it's a small little thing you're saying, mail me and I'll post
a summary.  Basically, I would like to get a very lengthly file on
what a debugger can and cannot do, and tips and techniques for all of
them.

It seems that MacsBug is be the low-end debugger.  I would think that
TMON and The Debugger would do everything MacsBug can do and more.
However, it seems that MacsBug has better and more documentation than
any of the debuggers out.

When I used The Debugger (original version) to debug an app I wrote on
an SE, it crashed as many times as did my application.  I have yet to have
MacsBug or TMON crash even once.  The documentation was piecemeal.  It had
a good tutorial but a horrible technical reference.  I can forgive home-
made packaging, but it's awfully hard to learn anything from a poorly
written manual.  Though Steve Jasik has lots to learn about effective
interfaces and documentation, from the popular opinion I've heard, he
seems to write good debuggers.  Should I upgrade my debugger so I can use
it on my Mac IIci now?

TMON looks incredibly powerful.  It's got its own scripting language,
it's amazingly user-modifiable, it's very robust, and aside from the
button bar along the top (ugh), the interface looks very good.  A little
more mousing is needed than I would like, but I find it far nicer to
use than MacsBug's CLI.  It's documentation is rather hard to follow,
though, and there's certainly not enough of it.  Kudos to Waldemar Horwat
adn Michael Bentley for trying to cram all that knowledge into two small
~200 page manuals, but there's too much information on what TMON Pro does
and not enough on how to actually *use* these features.

    - Scott

                      +----------------: SCOTT BRONSON :-----------------+
+---------------------|  [e-mail]    [e-mail] |
|       /_  /)        | 6850 El Colegio Road #234; Goleta, CA 93117-4300 |
|        / /_)        +==================================================+
+=========================+


+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Mon, 6 Apr 1992 10:49:03 GMT

In article <scott.702520229@mcl> [e-mail] (Scott Bronson) writes:
>I have reached a stage in my projects where I would like to use
>the most effective debugger know to Macintosh.  I own TMON, I have
>MacsBug in the wings and waiting, and (I bought this LONG ago) Jasik's
>MacNosy/Debugger.  I acutally really like debugging software because
>the gut-grinding frustration you feel is overshadowed by the incredible
>elation of finally stomping that bug out.  Or, perhaps, I'm taking
>debugging way to personally.
>
>It seems that MacsBug is be the low-end debugger.  I would think that
>TMON and The Debugger would do everything MacsBug can do and more.
>However, it seems that MacsBug has better and more documentation than
>any of the debuggers out.

Other advantages of MacsBug is that it is stable and reasonably extensible.
Versions earlier than 6.x were painful, but I like the current versions.

>When I used The Debugger (original version) to debug an app I wrote on
>an SE, it crashed as many times as did my application.

I'm glad someone else confirms my experience. Jasik's programs have a
tremendous functionality, but a lousy user interface and documentation.

>TMON looks incredibly powerful.  It's got its own scripting language,
>it's amazingly user-modifiable, it's very robust, and aside from the
>button bar along the top (ugh), the interface looks very good.  A little
>more mousing is needed than I would like, but I find it far nicer to
>use than MacsBug's CLI.

There are a few keys to learn with MacsBugs editing, and it certainly isn't as
powerful as TMON.

I'd like to add a few opinions about the two Apple source code debuggers:

SADE is powerful, but not easy enough to use. SourceBug is much nicer, and
doesn't lack much functionality you'd ever need. One problem I have with both
is that they won't work with standalone resources. SourceBug doesn't even debug
MPW tools (else, I would probably use it much more frequently).

Matthias

- -----
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Date: 6 Apr 92 16:56:11 GMT
Organization: University of Illinois at Urbana-Champaign

[e-mail] (Matthias Ulrich Neeracher) writes:
>SADE is powerful, but not easy enough to use.

SADE makes you spend quite a bit of time programming your debugger, rather
than debugging your program.  I find this frustrating, but it isn't the
end of the world.

I find SADE's performance quite acceptable; now that I have my Quadra.
Before that, SADE was sort of slow; again, not the end of the world,
but inconvenient.

What *IS* the end of the world (:-)) is that SADE is unable to view
the contents of variables before the current stack frame, if those variables
are in registers.  Compounding the problem is that MPW's C compiler lacks
a switch to keep variables out of registers. [Yes, I know that I could add
code to each of my declarations to force variables out of registers, but that's
a mess and a big pain in the tush.]  This is a major deficiency.

When I have a sticky debugging problem that doesn't involve the toolbox
(eg, parsing routines), I move the code to my cube and use gdb.  Gdb has
SADE beaten hands down in most areas, including the ability to inspect
previous stack frames.
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Mon, 6 Apr 1992 10:49:03 GMT

In article <scott.702520229@mcl> [e-mail] (Scott Bronson) writes:
>I have reached a stage in my projects where I would like to use
>the most effective debugger know to Macintosh.  I own TMON, I have
>MacsBug in the wings and waiting, and (I bought this LONG ago) Jasik's
>MacNosy/Debugger.  I acutally really like debugging software because
>the gut-grinding frustration you feel is overshadowed by the incredible
>elation of finally stomping that bug out.  Or, perhaps, I'm taking
>debugging way to personally.
>
>It seems that MacsBug is be the low-end debugger.  I would think that
>TMON and The Debugger would do everything MacsBug can do and more.
>However, it seems that MacsBug has better and more documentation than
>any of the debuggers out.

Other advantages of MacsBug is that it is stable and reasonably extensible.
Versions earlier than 6.x were painful, but I like the current versions.

>When I used The Debugger (original version) to debug an app I wrote on
>an SE, it crashed as many times as did my application.

I'm glad someone else confirms my experience. Jasik's programs have a
tremendous functionality, but a lousy user interface and documentation.

>TMON looks incredibly powerful.  It's got its own scripting language,
>it's amazingly user-modifiable, it's very robust, and aside from the
>button bar along the top (ugh), the interface looks very good.  A little
>more mousing is needed than I would like, but I find it far nicer to
>use than MacsBug's CLI.

There are a few keys to learn with MacsBugs editing, and it certainly isn't as
powerful as TMON.

I'd like to add a few opinions about the two Apple source code debuggers:

SADE is powerful, but not easy enough to use. SourceBug is much nicer, and
doesn't lack much functionality you'd ever need. One problem I have with both
is that they won't work with standalone resources. SourceBug doesn't even debug
MPW tools (else, I would probably use it much more frequently).

Matthias

- -----
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Date: 6 Apr 92 16:56:11 GMT
Organization: University of Illinois at Urbana-Champaign

[e-mail] (Matthias Ulrich Neeracher) writes:
>SADE is powerful, but not easy enough to use.

SADE makes you spend quite a bit of time programming your debugger, rather
than debugging your program.  I find this frustrating, but it isn't the
end of the world.

I find SADE's performance quite acceptable; now that I have my Quadra.
Before that, SADE was sort of slow; again, not the end of the world,
but inconvenient.

What *IS* the end of the world (:-)) is that SADE is unable to view
the contents of variables before the current stack frame, if those variables
are in registers.  Compounding the problem is that MPW's C compiler lacks
a switch to keep variables out of registers. [Yes, I know that I could add
code to each of my declarations to force variables out of registers, but that's
a mess and a big pain in the tush.]  This is a major deficiency.

When I have a sticky debugging problem that doesn't involve the toolbox
(eg, parsing routines), I move the code to my cube and use gdb.  Gdb has
SADE beaten hands down in most areas, including the ability to inspect
previous stack frames.
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 9 Apr 92 05:13:56 GMT
Organization: Peirce Software

I've been living inside Jasik's Debugger lately (I'm working part
time on a contract *just* debugging).

Jasik's Debugger has a few warts, mainly some weird UI things, but
it also is simply excellent at doing its job.

I view it as a industrial strength power tool.  Once you learn it,
you can perform miracles, but like other ISPTs it has to be mastered
with care.  It helps ALOT to have someone around who can teach you
how it works.

I know alot of programmers and almost all who are doing serious MPW
work use Jasik's Debugger.

Macsbug has it's place too - there are a few clever DCMDs floating around
that are handy.

I used TMON a little before it went pro.  I personally don't like
the pro version.  Its UI makes Jasik's look wonderful.

SADE.  Well, I really don't like debuggers that are just another app.
I find it much nice to have them hiding - no funny update problems
caused by them that.  SADE is an App and does get "in the way".

So, in summary.  If you are serious, take the time to learn Jasik's Debugger.
It's well worth the trouble!

- --  Michael Peirce         --   [e-mail]
- --  Peirce Software        --   Suite 301, 719 Hibiscus Place
- --  Macintosh Programming  --   San Jose, California USA 95117
- --           & Consulting  --   voice: [phone] fax: [phone]
- --                         --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (David Sumner)
Date: 9 Apr 92 13:57:02 GMT
Organization: Univ. of South Carolina, Columbia



Michael Peirce writes:

>I used TMON a little before it went pro.  I personally don't like
>the pro version.  Its UI makes Jasik's look wonderful.

Naturally, there is a lot of room for tastes in the choice of a debugger,
but just to throw my two cents in, I'll take TMON Pro over Jasik's
Debugger any day. I personally love the new TMON interface and
find it easy to use for my purposes. I do like NOSY a lot, however. I
use it at least as much as I use TMON - and that's quite a bit.

David Sumner


+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: Sun, 12 Apr 92 14:14:35 EST
Organization: EnigamI, Inc., Nashua, NH


In article <scott.702520229@mcl> (comp.sys.mac.programmer), [e-mail] (Scott Bronson) writes:
>I have reached a stage in my projects where I would like to use
>the most effective debugger know to Macintosh.  I own TMON, I have
>MacsBug in the wings and waiting, and (I bought this LONG ago) Jasik's
>MacNosy/Debugger.

>I would just like to hear what people thing of the object-level debuggers
>out today.  Incidentally, I use THINK C for everything right now, but
>I plan on buying MPW eventually (soon as I can scrape enough cash
>together).

I use MPW, and so have access to SADE, SourceBug, and MacsBug.  I
also own a copy of Jasik's Debugger.  I have never used TMON, so I
can't comment on that.

When I am debugging C++, I almost ALWAYS use Sourcebug and Macsbug
in combination -- they work well together.  There are some things
that I want Macsbug for, there are some things that I want Sourcebug
for.  Macsbug is a very good assembly debugger, but it can grok (translate)
C++ method names.  With its 'dcmd' capability, I have several very
valuable additional tools that have been added to it to do several
specialized tasks.  Macsbug is also always available.

Sourcebug is a source level debugger.  It works with a variety of
languages, but I think it secretly is in love with Object Pascal and
MacApp.  It does fairly well with Non-MacApp C++ though.  It is a
very easy to use, friendly debugger.  It also groks objects, which
is essential to me.  It is not all that powerful though.

SADE I almost never use.  I'm sure it is very powerful, with the capability
of writing scripts to calculate fibonacci numbers and all, but it
is really stuck in a world of Pascal.  You can debug C++ or C in it,
but the data structs end up smelling of Pascal.  Personally, I find
it to be a UI disaster, and very difficult to use more than about
20% or so of its capabilities.  The new version is supposed to be
able to use the MMU to protect code, but all it did for me was crash
my system and corrupt the Q900's RAM disk.

Jasik's Disast --- err, Debugger.  It is very powerful.  The documentation
is a mess, real spaggetti.  It does have a lot of abilities that the
other debuggers don't have: it can source debug C++ in an arbitrary
code resource, for example.  However, Steve Jasik has never heard
of the Mac User Interface guidelines, and when I mentioned the idea
to him, he commented that it would cost him $5000 to print up new
manuals to make it conform, and that was too much.  It also does not
support the Extended Keyboard, 'cause Steve doesn't own one.  Personally,
I found it really very painful to use, and when it and my Q900's RAM
disk could not co-exist, I stopped using it altogether. (I re-wrote
my Photoshop plug in as an Application, and now use SourceBug on the
Application.  It works, after a fashion, and I am much less frustrated)).

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Microsoft Free and Proud Of It!...
                           ...Microsoft Products: Just Say no.

+++++++++++++++++++++++++++

From: [e-mail] (Thomas R. Kimpton)
Organization: Digital Technology, International
Date: Thu, 16 Apr 92 00:03:28 GMT


One of the reasons I like MacsBug is that I can put it on
everyone's machine (it doesn't take an arm and a leg of RAM)
and rest assured that if something happens I can do some
quick and dirty debugging without worrying about licensing
hassles.  Although I do get questioned occasionally about
a weird window on their screen :-).

- --
- ---
Tom Kimpton                            [e-mail]
Digital Technology Int.                [phone]
500 W. 1200 South, Orem UT, 84057      FAX [phone]

---------------------------

End of C.S.M.P. Digest
**********************